Compatibility: This version of dataComet has been tested with various models of the Macintosh, and is likely to work with models from the Mac+ to the Quadra and PowerPC 9500 running Systems from 6.0.3 to 7.5.5. This version will work on the Mac+ and other systems running older versions of the Mac System, but you may experience problems.
Versions of Comet and dataComet prior to 4.40 have bugs which cause crashes when the application is launched with less memory available than the "Preferred" size. You should upgrade to 4.40 or higher to avoid this problem.
Menu-key equivalents are superseded by macro keys, but the menus are not corrected.
The Print command, when QuickDraw printing is used, does not space characters correctly when the dataComet-fonts are used to print foreign language characters, and will not use the dataComet-fonts with Background Printing unless they are installed in the System.
Some Macintosh configurations (such as those using an E-Machines display board) may "hang" soon after dataComet opens its first session windows if fast drawing mode is enabled. This occurs due to incompatibility between the display adapter and the fast drawing mode. To fix this problem, you can reconfigure your "Comet Default" document by launching dataComet, cancelling the initial Configure Session dialog, turning off "Enable fast drawing" in the Control Global... dialog, and pressing the OK button. (Another method is to throw out the "Comet Default" document in the System Folder.)
If you try to download a file to a locked disk, after the file transfer fails you will not be able to access that particular file again until you quit and restart dataComet; you will not be able to completely dismount the disk because the file will be "busy", although you can eject the disk, unlock it, and access other files.
Those using Ethernet should enable asynchronous sends, because there is a major drawback to using synchronous sends: until the host acknowledges that it has received the data you have sent, the Mac will seem to "hang." Although the mouse cursor will move, the Mac will not respond to mouse button-downs or keystrokes until the acknowledgment is received; in the event of a communications problem with the host, this can leave you hanging for minutes! If this occurs, you should NOT reboot your Mac, but should wait for the send to either complete or abort.
If you're using two monitors and the primary monitor has less color depth than the secondary monitor the color mapping in an emulator window will be restricted to the palette available on the primary monitor even if it's displayed on the color screen. (E.g., the primary is 16-greys and the secondary in millions of colors). You can use the "!Ck" macro to fix this problem and always give the best available color mapping (at some cost in the emulator's drawing speed; you can use "!CK" to go back to dataComet's default behavior).
System 7.0 notes:
The Macintosh Toolbox routine which Comet uses to draw color text performs very slowly with non-white backgrounds under System 7.0. You should probably upgrade to 7.1 or higher.
dataComet as of 4.1.7A appears to work correctly with Open Transport on the 9500. Comet 3.1.3 is reported to work correctly with betas of OT 1.1, but users are encouraged to upgrade to dataComet 4.40 or higher to take advantage of enhanced functionality and significant bug fixes.
OT1.1 is much more reliable than previous versions of OT.
System 7.5.3 and OT 1.1 are strongly recommended for PCI Macs.
OT as of 1.0.7 does not support the MacTCP Status call which is supposed to
report statistics. By default, dataComet no longer uses these calls; a
Control Global option has been added to enable this for non-OT machines.
OT as of 1.0.7 does not support the MacTCP Status call which is supposed to report statistics. By default, dataComet no longer uses these calls; a Control Global option has been added to enable this for non-OT machines.
OT 1.0.5B4 has a bug which causes it to report the Maximum Segment Size incorrectly, which caused dataComet to fail when attempting to create a session. dataComet 4.1.4A has been modified to handle this problem.
If dataComet reports that the Domain Name Resolver can't be opened, the "MacTCP DNR" file in the System Folder should be replaced or trashed (so that it will be re-created by the MacTCP driver automatically; note that GateKeeper or other security tools may abort this, so you need to have security disabled when re-booting for trashing the file to work).
Several versions of MacTCP are available; the best version is 2.0.6. 2.0.4 is also reliable. Herewith are the advantages and drawbacks of each:
2.0.6: Seems to be about the same as 2.0.4 with dataComet, although it seems more prone to hang than 2.0.4 when performing Fetch FTP transfers.
2.0.4: Finally a version of MacTCP which seems to have most of its problems fixed. The packet retransmit timeout behavior has improved, but you may want to configure dataComet to lower the Resend Time Out by default, since the 1-second floor seems quite high for an interactive Telnet session.
2.0.2: Apple has worked some on the problem with resending lost packets too slowly, however it is not fixed.
1.1.1: Apple strongly advises that 1.1.1 be used with System 7.1; however, 1.1 seems to work OK as long as Virtual Memory is off. This version fixes several bugs in previous versions: e.g., it displays the LocalTalk icon properly in the Control Panel, does not crash on the Mac+, and apparently handles asynchronous sends correctly . Unfortunately, it waits from 3 to 15 seconds to resend a lost packet, which can make it unusable with ASCII hosts on networks with high rates of packet loss.
dataComet does NOT try to fix MacTCP's resend behavior by default. You can enable this behavior by using the macro "!tD". You can display MacTCP's resend timers by using the macro "!CD"; you might want to take a look at this if you've been having trouble with SLIP.
1.1: Required for System 7 up to 7.1. This version crashes on the Mac+. The LocalTalk icon does not always appear in the MacTCP control panel when LocalTalk is the selected Network device.
1.0.2: A special version of MacTCP 1.0.1 released to improve the performance of MacX. This version is known to cause crashes on some machines.
1.0.1: The first functional release version of MacTCP. Asynchronous sends under LocalTalk are definitely hazardous with this release, resulting in machines hanging with the cursor frozen. 1.0.1 works under System 7, but only if Virtual Memory is off and a copy or alias is placed in the System Folder so that Domain Name Resolution will work properly. Using 1.0.1 with System 7 is not recommended.
In general users experiencing crashes when using MacTCP on an Ethernet are suffering from the presence of a dysfunctional 'ENET' resource in the System. Installing the most recent version of the Apple Networking software usually fixes such problems.
E.g., some versions of the Asante drivers have been unreliable when used with MacTCP, resulting in seemingly-random crashes. These often occur due to conflicts with MacTCP, which cause MacTCP to call a debugger trap (which crashes your machine if you have no debugger installed!) If you are using an Asante Ethernet device, you should install the Apple Networking software using the Installer on your System disks.
You can enhance your communications efficiency when using the 3270 emulator by making sure that XEDIT has "SET FULLREAD OFF" in your PROFILE XEDIT file; XEDIT-based applications such as RICEMAIL may need to have this option turned off also to get optimal performance. FULLREAD mode causes an extra 2,000 bytes to be sent with every PF-keystroke in the Action menu, and can significantly degrade performance on slower networks such as LocalTalk.
Nota Bene: The MacTCP driver interface can have asynchronous sends enabled; in this mode, Macs using MacTCP up to 1.0.2 on LocalTalk will be prone to crash (with the cursor frozen and the whole machine hung). You can configure this option in the Global Configuration dialog. MacTCP 1.1.1 works properly when asynchronous sends are enabled.
These are often the most complex and difficult problems to resolve due to the variety of settings possible and the vagueness of the RS-232C port on most modems (which is interfaced to an RS-422 port on the Macintosh).
If you're using hardware handshake, which is the preferred mode, make sure that you have a cable which supports hardware handshaking. If you are experiencing data loss or errors in transmission, try lowering the baud rate to 19,200 or 9600; if your cable is not of good quality and there is a lot of EMI present (Electrono-magnetic Interference) from other computers or electronic devices, the signals on the cable may be corrupted by the interference.
